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(54) Method of and apparatus for providing secure dislrlbuted directory servicee and public key 
infrastructure 



(67) In an exemplary embodiment the sender re- 
ceives the clienrs Oistingutshtng Name (DN), and then 
searches its directory tor identtfication information and 
access control rights for this specific context. The server 
can act as a stand-alone server or in conjimction with 
other directory sewices on the network. A client must 
have a verifiable klentity in order for secure communi- 
cattons to continue. A client's klentity can be saki to be 
fully verifiable if the senrer has access to the directory 
senrk^e that maintains that client's DN. The client re- 
ceives the sender's DN, and the client can then deter- 
mine whether or not to accept a response to a request 
for informatton (i.e.. tnisl the response). The client de- 
termines the klentity of the sender using some directory 
sen^ice (the client can act stand-akxie or as a client of 
other directory servers). A server is fully verifiable if the 
client can identrly the directory service that maintains 
the sen/er's DN. In both cases, determining ktentily is 
predicated on being able to identify a directory servce. 
Since senders and clients are issued kientities (DN*s) 
from some directory senrice before they participate in 
secure communk^ations. they are able to at least kientify 
their 'home* directory senrce. Their 'home* directory 
sen/ice communrcates with other directory services, 
each "serving" their lists ot electronic identities to each 
other using secure directory services In this manner a 
client or server can verily the peef identity ol a secure 
communicator by relying on tne trusted 'home" directory 
service Public Key certificates ccrtilicaie revocation 



lists, pending certifk^ate requests, Certifk:atkxi Authority 
policy, and other information is stored in the directory 
sender. Access to the directory eerver is through secure 
communications; this maintains the integrity and privacy 
of the informatton. 
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OMcrlptlon 

BELD OP THE INVENTION 

The invention generally relates to the field of cfigital 
data processing communications systems in which a us- 
er at a wodotation requests information or sennces from 
a server computer. More particularly, the invention re- 
lates to a method of and apparatus for pioviding a pubKc 
key infrastructure via secure directory senrices within a 
computer system andtor a computer netwrorfc. 

BACKQROUND AND SUMMARY OF THE 
INVENTION 

With the widespread and ever mushrooming use oi 
network-based communications, a business worM 
where electronic-based business transactions are the 
rule rather than the exception has been a tongstanding 
vision shared by many, A major stumbling bloclito wide- 
spread electrons business transactions is the need to 
effectively depk>y a secure communications system pro- 
viding privacy, message integrity, non-repudiation and 
authenticity. 

Cryptographic systems have been widely used to 
ensure the privacy and authenticity ot messages com- 
municated over a wide variety oi diftereni networks 
Many conventional crypiosyslems are not satisfactory 
lor widespread business world depte>yment due to well 
recognized problems relating to, for example, key dis- 
tribution 

Public key cryptographic systerm have been ad- 
vantageously utilized to solve existing cryptographic 
system problems including key distribution problems. 
Such public key cryplo^hic syetems use a publk: key/ 
private key pair and decouple the encrypting and de- 
crypting processes such that the encrypting process key 
is separate and distinct from the decrypting process key. 
In such systems, given the knowledge of the encryptkx) 
key and an enciyptMn key that is large enough, it is not 
viable to oompUe the decryptkin key and thus the en* 
crypinn key for users may be dislrituted or published. 
Anyone desiring to oormunlcate with a user at a partic- 
ular destination, encrypts a message under the destina- 
tion user's public key. Only the destination user re- 
tains the secret decrypting key of the public key/|pnvate 
key pair is able to decipher the transmitted messages. 

In public key cryptographic systems, it is known that 
a trusted authority may create a digital message virhk:h 
contains a claimant's public key and the name of the 
claimant. A representative of the trusted authority digit- 
ally signs the digital message with the authority's own 
digital signature. Such a digital nr)e$sage. referred to as 
a digital certificate is transmitted along with the use of 
the claimanl's own digital signature. See U.S. Patent 
No. 4,405.829 issued to RIvest et al.. whwh disctoses 
exemplary methodology for a practical public key cryp- 
tographic system implementation. Also see U.S. Patent 



No. 5214 J02. whKh describes a pubUc key digital sig- 
nature cryptographic system having enhanced digital 
signature certification. 

Existing pubfc key cryptography methodotogles en - 

5 vision that electionlc business transactions emptoy a 
gtotal standard for tying the public key use to a high 
level gtobal authority, using what is referred to as the X 
500 standard. Not an users, however; partwipate in thie 
gtobat etandaid. thereby limiting the standard's practcal 

10 utility. 

The present medtodotogy does not rely on a global 
standard. In accordance with an exemplary embodi- 
ment of the present inventkxt, cryptographte keys may 
be resNtont in a user's own directory services, while per- 

is mttttng users to securely communcate with each other 
as a result of using the dlstrtt>uted directory sen^ices de- 
scribed herein. The present inverUton utilizes secure 
distributed directory services to maintain a public key 
infrastructure, and does not operate in the conventwnal 

20 gtobal. top-down hierarchy using a ■meta<ertifier*. who 
must certify all users in order to provkle the desired level 
of security. 

In aocofdance with an exemplary embodvnent, us- 
ers may receive digital certificates from varous other us- 

ss ers and still securely communicate with each other with 
sufiicient security such that electronic business trans- 
actions may be culminated. The present inventkjn incor- 
porates the use of policy statements which efficiently 
permit trust levels to be applied to a user's sen/ice re- 

30 quest based upon an analysis by the recipient of the 
message sender's identity via the distribuled directory 
sen^ices system. Thus, the fact that a particular mes- 
sage sender is kjentified in a given distributed directory 
service using designated policy statemenAs, pemnits the 

3$ noessage recipient to determine the degree ol trust to 
be given to a message sender. 

The exemplary embodiment implenrtanls the con- 
cept that by being able to uniquely UenlByaclientina 
specific comnrujnfeattons context, a eerver can assign 

40 the client with specifc access rights forthat context. The 
access rights granted to a client depend on the dienfs 
ktentity in that context 

Given that access rights are based on klentity» the 
feature of being able to uniquely ktentay a client be- 

45 comes signricanl The sen^r requires a secure and in- 
fallft)le nrathod of kientrfying the client The Infallible 
method is based on using secure directory services of 
the nature described in the present exemplary embodi- 
menl By securely receiving ktentity verifkation sendees 

SO from a directory service, the server can then determine 
the access rights to grant to a client This altows a senrer 
to deliver client-eensitiva information, without prior 
knowledge of the client 

In accor da nce with an exemplary erhbocfiment of 

ss the present inventkm. a client initiates a secure connec- 
tion with a senwr provUing directory services. The send- 
er taking advantage of the authentication feature in the 
secure communicatxxis methodok)gy described herein, 
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uniquely identifies the client and thue obtains the client's 
distinguished name pN). The sender uses the clients 
DN to determine what accees rights to grant the client, 
either tiy looking up the client e DN in its own directory 
or by recursivety acting as a client to another directory 
server that containa definitive information about that 
particular DN. The directory server then returns the in- 
formation to the client that is specific to that client and 
is able todo so by taking advantage of theauthenticatkxi 
feature provided by the secure communicatkxis meth- 
odok)gy used herein. 

In accordance with another aspect of the present 
Inventkm. a client initiates a secure communicatton with 
a sen/er The methodok>gy described herein Is also ap- 
plicable to the instance where the client and server are 
on the sanr>e machines so that the network described 
herein may be Intemal to the computer in this special 
case. The server is able to unk^uely identify the client 
based on the authentication feature ol the secure com- 
municalions server as a directory service to verify the 
identity of the clients DN and for access control permis- 
sions to grant to the client. This communicalion with the 
directory service must be over a secure communica- 
tions channel because the information passed on to the 
client/server communicalion depends on the result and 
verifjcation and access rights leturned by the directory 
service The directory seivice responds to the server 
with veriticalion ir^lormation and access control inlorma- 
tion. particular to that client and the server is able to de- 
termine what tnlormation should be sent lo the client. 
The sen/er then returns either none, some or all the in- 
formatkxi requested by the client. 

In an iUustrative embocfiment. the ktentities of the 
pariies involved determine the access rights tor a direc- 
tory senrce*s communications context. All requests for 
Inlormatkxi made by the client, receive customized di- 
rectory service responses. The peer identities are de- 
termined through the use of secure communications. 

In an exemplary embodiment the servw receives 
the clients Distinguishing Name (DN). and then search- 
es its directory for identmcatkxi intormatkyi and access 
control rights for this specific contact. The sender can 
act as a stand-atone server or in conjunctkxi with other 
directory services on the network. A client must have a 
verifiable ktontity in order for secure comrrumkations to 
continue. A clients Mentity can be said to be fully veri- 
fiable if the senrer has access to the directory sen/k:e 
that maintains that clients DN. 

The client receives the server's DN. and the client 
can then determine whether or rK>t to accept a response 
to a request tor inf omiatton (i.e., trust the response). The 
client delemnines the toemlty d the senrer using some 
directory servce (the client can act stand^tone or as a 
client of other directory servers). A senrer is fully verifi- 
able it the client can identity the directory senrk:e that 
maintains the server's DN 

In tx)th cases, determining identity is predicated on 
being able lo identify a directory service. Since servers 



and ciente are issued toentities (0N*8) from some direc- 
tory-senrice before they participate in secure^communi* 
cattons. they am able to at least ktontify their "bonne" 
directory servce. Their "home' directory senrice com- 

s munteates with other directory eenrices, each 'senring' 
their lists of electronc ^entities to each other using se- 
cure cfirectory services. In this manner, a client or sen^r 
can verify the peer kfentity of a secure communicator by 
relying on the trusted "home' directory service. 

TO Ttte present exemplary implementatkxi ol the in- 
vention can be used to implement a Public Key Infra- 
structure in the following manner. Pubfic Key certifi- 
cadss. certificate revocatksn lists, pending certifkate re- 
quests. Certifk^tion Authority policy, and other intonna- 

IS tkxi is stored in the directory senrer. Access to the di- 
rectory server is through secure communicaittons; this 
maintains the integrity and privacy of the informatton. 
Administrators acting in the capacity of the Certification 
Authority are granted full access to the repository, by 

so Issuing them the 'Administrator's ON*, andean add new 
certificates, modify certificate revocation lists, eto. Oth- 
ers woukf have less access, to the limit that unknown 
pariies may only be alfowed to submit certificate re- 
quests or download public certificates (and revocation 

2S lists). Additionally, certificates can be used as vectors in 
directory searches: the client attempting the directory 
search has its access limited by its client DN, and the 
clients DN may not contain a name at all but rather a 
hash of the clients policy In this manner, certificates can 

30 be issued that contain minimal information; in fact, they 
only need to contain a unk^ue identifier that can be used 
as a vector in the vector space (this wouto be the entire 
namespace that is visble to that paittoular cfienl). 

35 BRIEF DeSCWPnOW OF THE DRAWINGS 

These as v^l as other features of this inventton will 
be better appreciated by reading the following descrip- 
tton of the preferred embodiment of the piasent inven- 
40 lion, taken Into conjunction with the aooompmying 
drawings of which: 

FIGURE 1 is a btock diagramof an exemplary com- 
municatkxis system within whk:h the present inven- 
45 tkxi may be utilized; 

FIGURE 2 Is a data flow diagram showing illustra- 
tive data comnnink^ted between a directory client 

and a server; 

so 

FIGURE 3 is a data ftow diagram exempfifying how 
a diem may be ktentffied in awcure oommunlca- 
tions protocol; 

S5 FIGURE 4 is an example of a digital certifk^te 
which may be used in conjunctkxi with FK5Uf=1E 3; 

FIGURE 5 is a flowchart of the general sequence 
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dt operations performed in accoidance with an ex- 
emplary embod im ent; 

RGURES 6A and 6B are a flowchart delineating an 
exemplary sequence of operations involved in the 
tdentffication verification process; 

FIGURE 7 is an exemplary verification descriptor 
obiect^data structure; 

HQURE 8 Is an exenrv>lary context descriptor ob- 
ject/data structure; 

FIGURE 9 is an exemplary data sUucturetobject uti- 
lized in conlunction with FIGURE 6A. block 80, ver- 
ification analysis; 

FIGURE 10 ts an exemplary object data structure 

used in perlormtng verification analysis of FIGURE 
6A. block 86: 

FIGURE 11 is an exemplary object used in perf onm- 
tng the verificatk>n analysis of FIGURE 6A, block 

90; 

FIGURE 12 is an exemplary object/data structure 
used tor retrieving an access contiol list rule. 

FIGURE 13 is an access list control rule object/data 
structure. 



DETAILED DESCRIPTION OF AN EXEMPLARY 
EMBODIMENT OF THE INVENTION 



Figure 1 shows in bk)ck diagram fomn. an exemplary 
computing system within which the present invention 
may be utilized as part of an electronic commerce/com- 
municatlorw network. It should be recognized that, wtitle 
the present nrwthodology may be utilized in such a coov 
munteations network environment, the invention may 
likewise be used in conjunction with a wide range of data 
processing systems, including one or more laptop oonrv- 
puters, stand-atone. PC-type computers, mi npom p ut- 
ers, and any other computer system environment where 
data security is a significtfit concern and practically inrt- 
plementabte. 

Before describing an exemplary communk:atk)ns 
system, which may be used In conjunction with the 
present invention terminology utilized herein is first de- 
scribed. A •client process' or program runs on a com- 
puter attached to a network. The client process is dis- 
tinguished by the fact that it makes requests for infor- 
mation or servk»s. The cKent process may be referred 
to herein as a client. 

A *senrer process* also runs on a oomputer at- 
tached toa network. The serverprocess is distinguished 
by the fact that it lulfills requests for information or serv- 
ices The server process may be referred to herein as 



asen/er. It shouW be recognized that aclienl and a sew- 
er may actually run on the same computer and that a 
server may be a client to another senm. 

As used herein, "secure oommuncattons' typk:ally 

5 refers to any data transport mechanism, v^ich prefera- 
bly provWes, but is not limited to. privacy, message in- 
tegrity, non-repudtation, ar)d authenticity. 

A •Distinguished Name" <DN) unk^uely dentifles an 
entity partkapatinQ in a digital conversatkxi preferably 

to enabled via secure communications. 

A •communfcations contexf is an Instance where a 
client is requesting information from aome server, and 
the request for informatkxt can be distinguished by one 
or more of the foltowing: client ON, sender ON. Inlonma- 

iB tkm requested, infonnatkxi avaOable, and access con- 
trols on that intormatton. 

Turning back to Figure 1 . this figure shows an ex- 
emplary conrtmunicattons network including multiple cli- 
ent computing devfces. and combinatkx) client/sen/er 

20 computing servrces rilerconnected via local networks, 
and through an Internet The local area networks (LANs) 
shown in Figure 1 . i.e.. LAN 1 and LAN 1 3 are depicted 
for illustratton purposes only These networks are in- 
tended to be representative of any of the nnany network 

2S designs, such as Ethernet, token ring, or other type of 
networks having attached clients and servers which are 
likewise intended to be subsumed by the Figure 1 archi- 
tecture. By way of example only. LAN 1 may be an Ether- 
net 802.3 10 base T network. A variety of protocols run 

30 on LAN 1 . including TCP/IP and NETBIOS. Although nu- 
merous protocols may be running on LAN 1. TCPVIP is 
preferably utilized, whk^h is the protocol that runs on the 
Internet. 

As shown in Figure 1, l-AN 1 includes a PC-type 
3S computer 2 operating solely as a dienL whk^h may. for 
exarrple, be a Windows d5-based workstation. LAN 1 
additionally inckides a wortotatkxi 3 which may. lor ex- 
arrple. be an IBM RS 6000. operating as both a client 
and a server The IBM RS 6000 typk:alfy njne the AIX 
40 operating system. Client/torver 3 may be running as a 
client in the context of the methodology described herein 
ancVor as a senw having its own XSOO directoiy space. 

LAN 1 also inckides a minicomputer eenrer 4, which 
may be any commercially available mintoomputer. Min- 
45 kxxnputer sender 4 may, for exan^le. be dedicated to 
provtiing digital certifcates or directory sennces. Mini- 
computer server 4 may be attached to another network 
(not shown). As suggested by inclusion minnonr^puter 
server 4, servers are not limited to workstatkxt type de- 
vices. 

LAN 1 may. for example, also include a giaphk^- 
based SGI client/server 6, which may be one of the 
workstations manufactured by Silk:on Graphics Corpo- 
ratkxi. Client/server 6 may perform computer graphics 
ss and^orCADoperatk)n8.Workstatkxi client 8may. for ax- 
ample, be an IBM PC-based work station and is repre- 
sentative of the numerous additional available worksta- 
tions which may. if desired, be coupled to LAN 1 . 
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The eecure communications with directoiy een^ices 
or the present invention occur not only on the exemplary 
LAN 1 . but also on LAN ia LAN 13 also runs protocols 
including TCP/IP for Internet communication. 

LANs 1 and 13 may. for example, oommunicate via 
the Intemet 22. via routers 16 and ie. Routers 16 and 
18 are conventional routing computers for Intemet com- 
munications, having sufficient memory capacity to per- 
form necessary routing functions and keep track of the 
devices with which they are associated on the Intemet 
A router provides a quick connection between two de- 
vices on the Interrtet. A router 16,18 may serve more 
than one LAN. The routers 1 6 and 18 may. lor example, 
be routers commercially available from Cisco Corpora- 
tion. 

Various other clients such as Smart Card Reader 
20 and laptop client 24 may be attached to. and com- 

municaie with, any ol the other depicted devices through 
the Intemet via phone lines 23.25 Smart Card Reader 
20 may. lor example, be a Visa card reader. With respect 
to Smart Card Reader 20. althou^ the concept of a 'cli- 
ent' described thus far has been applied to a program 
requesting infonnalion or services, a client may also be 
hardware or circurtry embodied in. for example, a Smart 
Card Reade* requesting inlormaiion or services 

LAN 13 rncludes a clieni/server 12 whtch mhy lof 
example be a SUN Microsystems SPARC which is a 
RISC-based workstation. LAN 13 also includes a client 
workstation 10 which may be a Mac li. manufactured by 
Apple Corporation, and a client/senrer 14. which may 
be a DEC workstation. Workstations 10. 12 and 14 are 
exemplary workstations which may be coupled to a LAN 
each of which may be running different operating sys- 
tems. 

Although the LANs 1 and 13 are coupled together 
via the Intemet 22. the method and apparatus may be 
advantageously utilized without Internet connections. 
Thus, for example, an tntraoffee net¥vork may distribute 
digital certificates and secure information in accordance 
with the present inventkyi. It should be understood that 
the present invention may be employed with any subset 
of the stnicture shown in Figure 1 . 

Figure 2 is a data now diagram showing illustrative 
data communk:ated between directory cKent 40 and 
sen/er 42. In accordance with an exemplary embodi- 
ment of the present invention. The directory client 40 
may be. for example, any of the enumerated clients pre- 
viously described atxive in conjunction with Figure 1 . 

Simiterfy. sender 42 may be. for example, any of the send- 
ers identified above in Figure 1 . The directory server 44. 

the secure communications protocol component 46, the 
directory access component 46. arKJ the internal direc- 
tory database 50 are resident in server computing de- 
vice 42. As set forth above, directory client 40 requests 
intorrr^tion or sen/ices from a server 42. Client 40 is 
identified as a directory client and is therefore seeking 
direciory information The directory ilselt may be disirib- 
uied and reside virtually anywhere in the Figure i nei- 
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work. The directory stores infonnatkjn regarding individ- 
ual users and corporate entities euch as. for example, 
may be contained in a white page directory. For -exam- 
ple, the directory may include client data Inducfing aOis- 

5 tinguished Name or another unxfie dient kientifier. In 
addition tothe client ktontlfier. a directory may slorepub- 
lic key information for kJentifying the publfe key of the 
party to whk:h it is desired to securely communk:ate. Di- 
rectory Senrer 44 within sen/er 42 operates in accord- 

to ance with a preestablished directory protocol to sen^e 
directory informatkxi to cfirectory clients. If the cfireclory 
sen/er 42. by accessing its associated internal data 
base 50. can adequately respond to thet^lienfe directory 
related query, server 42 appropriately responds. If not. 

IS the question may be responded to by sewer 44 by re- 
turning a referral to directory dient 40 to Mentify the k>- 
cation of a server virhlch can respond. Alternatively, di- 
rectory server 44 may be chained to other directory send- 
ers and may attempt to find the answer to the inquiry, 

20 rather than sending a referral to directory client 40. In 
this context, the directory senrer 44 operates as a client 
to another directory sender. 

The secure communicatkms protocol component 
46 ensures that the directory client 40 communcates 

2S with directory server 44 using a secure communications 
protocol The secure communications protocol prefera- 
bly provides privacy, authentication, non-repudiation, 
and integrity to the communications between client 40 
and server 42. In conventional systems, no response is 

30 provided when a client is not entitled to access a sender. 
In accordance with the present invenlkm, a response 
may be obtained from a directory server which hdicates 
whether the client 40 has enough priviege to gm the 
requested information as will be descrt)ed further be- 
as tow. 

The directory access component 48 of senrer 42 
pemoits communication with the^enrar^ IntemaldatB- 
base 50. The server 42 determines via the direct aooess 
conrponent 48. what type d access the dient 40 is en- 

40 titled to have. 

In operation, in accordance with etep^ sender 42 
receives the dient kJenllty from the diredory client 40 
using the underlying secure communications prolocd. 
Because the communications protocol provides authen- 

45 ticity assurance, the client is securely ktentified so that 
the sender receives a known klentlty whch'Can later 
verified. 

Figures 3 and 4 show an example of how a client 

may be identified using a secure communk:aik3n8 pro- 
so tocol. As exen^lified in figure 3. client 60 initiatesvom- 
munication with servere2 by opening up a network con- 
nection to the server. The precise matter d initiation wTO 
depend on the nature d the network. Server ^ re- 
sporKto to the connectton ar^d demarrds that client 60 
55 identify itself. Client €0 then sends its identity for this 
communication sesston in the form d a digital certif k:ate 
to server 62 By v^y of example only, the secure com- 
municalbns protocol utilized may be the commercially 
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available SSL protocol, which in aocordance with the 
present invention is advantageously applied to directory 
servioes to provide a secure directory senrices systera 

Figure 4 is an example cA a digital certOicate 64 
which may be used to identify the client as described in 
conjunction with Figure 3 above. The digital certificate 
may be, but is not required to be. structured as recom- 
mended in the X.509 standard. The certificate may be 
custom designed to include numerous dmerent and/or 
additional fields as desired. The certificate may be writ- 
ten, for example, in ASN. 1 syntax. The digital certificate 
64 includes a "certificate* field which is a digitally signed 
sequence, that includes a hash of the data identified be- 
low, which is then encrypted with the signing party's pri- 
vate key. Within the information that is digitally signed 
is a version number, a serial number which uniquely 
identifies the certificate, and the signature of the signing 
party in accordance with an identified algorithm such as 
RSA Additionally included within the signed certificate 
information is an identification ol the certificate issuer, 
identifying the name of the party that signed the digital 
certificate. The certificate includes a validity field which 
specifies how long the certificate is valid. The subject 
field specifies the name of the party who holds the cer- 
tificate, and the public key information field specifies the 
public key of the subject The fields referred to above 
are expanded in Figure 4 to show theu consliluent con- 
struction in more detail. Figure 4 thus shows an exem- 
plary data structure of a digital certificate which may be 
used in conjunclion with the present invention. 

Turning to back to Figure 2, in accordance with step 
2b. the server 42 checks if the client identity is recog- 
nized by the internal directory data base. Thus, if direc- 
tory client 40 tfansmUs cKant identity infonnation in the 
lorm <A a digital certificate, such as that shown in Figure 
4. sender 42 checks the digital certificate to confirm rec- 
ognitk)n from its internal data base 50. The sender 42 
inttiaily checks the digital certifcate to confirm that the 
signature of the issuer matches the signer's si^ture. 
Thus, if the internal directory data base 50 has no infor- 
mation regarding the certificate'^ signer, the client witt 
not be identifiable. Under such circumstances, the senr- 
er 42 may act as a client to retrieve the required signer's 
public key information from another senrer to complete 
the identification. Details of this process are descrbed 
in further detail in conjunction with Figure 6 and subse- 
quent figures described below. 

Once the identity of the client is verified, the internal 
directory returns an access control rule to apply to the 
client's communication session. ARemativeiy. it may re- 
turn an access denied In the case of an untrusted client. 
Once the client's identity is confirmed, an access control 
list is aeoessed to retrieve the access niles that apply to 
the communicatnns session. This intomnation is re- 
turned to the directory servce protocol 46 via the direc- 
tory access computer 46. 

With respect to step 2d. the communications ses- 
sion IS established with the client and the retrieved ac- 
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cess oontrol rules are applied to the coflrununk:ations 
sessioain this fashkxi. a cfient may be precluded from 
retrieving directoiy information that it is not entitled to 
retrieve, as specified by access control niles. While f ig- 

s ure 2 shows the communication between a directory cli- 
ent 40 and a directory server 42, the methodology is in- 
tended to be applied to a client and senrer. For example, 
the server may act to retrieve access control rules for 
cDente going to its web site. 

YO Figure 5 shows in flowchart form a general se- 
quence of operations performed in aooordance with an 
exemplary embodiment ol the present invention. As in- 
dicated in Figure 5. initially the client sends its Distin- 
guished Name (DN) which uniquely Uentifies the client 

IS (70). Thereafter, the sender receives the distinguished 
name DN (72). 

As suggested by block 74. the server analyzes the 
client DN to determine the appropriate ACL access con- 
trol rules to apply. As indicated by the 'recursive' par- 

20 enthetical in block 74, the server may access other di- 
rectory servers throughout the Internet in order to deter- 
mine the appropriate access niles to apply. In addition 
to access control rules, degree of tnjst related infonna- 
tion which may be associated with the client also may 

25 be accessed from different servers on the Internet. The 
server, by making requests toother directory servers on 
the Internet, itself becomes the client in its effort to pro- 
vide the access control and trust rules to apply to the 
client. Thus, in the context of a web site, if a client sends 

30 its distinguished name DN (or an alternative identifier) 
to a web site, the web site needs to ktentify the client 
either at an interna) data base at its associated sender 
or at other web sites. The web site can then seek ben- 
tifying informatnn from other directory sen^ web sites 

36 until a tnistrelatksnshipwim the requesting Client is de- 
tennined. With such informallon retrieved from other di- 
rectory senders, the degree of tnist which may be asso; 
elated with the requesting cliertt may be determined. 
If the client is verified in block 74 processing. ACL 

40 inf omnaton is returned to the directory senwr as indk»t- 
ed in block 76 and is applied to the dataconnection. The 
accesscontrol rules and trust related formation are ap- 
plied to the data connection to ensure that actions lake 
place <junng the data connection In accordance with the 

4S access control niles and^r the trust information, to 
thereby ensure that authorization levels are not exceed- 
ed. 

In accordance with this methodology, for example, 
a digital certif k:ate possessed by a party which has been 

50 issued by Visa may be transmitted to a wsb site and an 
electronk: transaction may take place, whereby goods 
are purchased. The transaction may be completed In ac- 
cordance wHh the citenrs credit rating tii*tk:h may be 
checked, for example, through Vlsa*e ^rectory senrer. 

SB The Visa directory server may determine the nature d 
the credit rating to transmit depending upon the partic- 
ular context, e.g.. the party at the web site requesting 
the information and the individual client. During this 
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process, the vveb site would likewise be transmitting to 
the Visa directory server its digital certrTicate so that the 
Visa directory server can determine whether the web 
site is. for example, a business which has recently gone 
banlaupt. or another bank which should be associated 
with a great deal of trust. In this fashnn, the present in- 
vention enables the transactton parameters to be fully 
devek)ped in the particular communications or business 
transactk)n context 

In accordance with Figure 5 at block 78, having ob- 
tained the appropriate access control list mles and^ 
trust intormation, such information is applied to the data 
connection. The data requested is transmitted t>8Ck to 
the diem, as shown in Figure 5, although the access 
control nile or trust level infonmatxm would not be com- 
municated. The process may be repeated in connectk)n 
with different sut>sequent communk»tion sessions. 

Figures 6A and 6B are a flowchart delineating the 
sequence of operations involved in an exemplary iden- 
tification verification analysis. The Input data to the di- 
rectory sen/er verification analysis component is the cli- 
ent identity which may include the digital certificate as. 
for example, shown In Figure 4, communicalions con- 
text inlormatton which is a context descripior that de- 
scribes the nature and/or type of communicalion and a 
servei (deniny which is the server's diciiai ceriificaie 
The directory server verification analysis flowchart 
shown in Figures 6A and 6B is implemented by software 
embodied within the directory sender 42 shown in Figure 
2 

Figure 7 is an exemplary verification descriptor ob- 
ject and Figure 6 is an exemplary context descriptor data 
structure utilized in the verifk:ation analysis shown in 
Figure 6. Turning first to the verifk»tion descriptor, the 
data structure^ed shown in Figure 7 includes a digital 
certificate Identifying the client and a digital certificate 
identifying the sender as well as a context descriptor. In 
the case of a null context descriptor, the context defaults 
to that of the directofy sewer protocol. Thus. H there is 
no context descriptor, the context is pre8unr>ed to be a 
communication sessnn between a client communicat- 
ing with a directory server. ARematlvely. It a web client 
is communicating with a web senrer and the web sewer 
is performing a verifkatkm analysis, then the context de- 
scriptor Is set to Indicate a web sewer communicating 
with a web client. In the case of a null sewer Identity, the 
sewer defaults to the directory sewer itsel! II commu- 
nication takes place between a web client and a web 
sewer, the web sewer inputs its web identity via its dig- 
ital ceniticate. 

As Shown in Figure 8. the illustrative context de- 
scriptor includes a version number fiekj and a time fieki 
which indicates the coordinated universal time. The 
"protocol' field varies depending upon the particular 
communications context. For example, if a web sewer 
IS communicating with a web client, the protocol may be 
the web protocol "htlp* If an E-mail chent ts communi- 
caiinq with an E-mail sewer then the protocol may be 



the 'SMTP" protocol. Addittonaly. any parametere de- 
fined by the protocol may be listed in the context de- 
scriptor. 

Tuming back to figure «A, blocks, the directory 
s sewer cheeks that the digital certificate issuer^ public 
key is available lo the directory eenm. for example, if 
Visa issued a digital certificate to a requesting party, a 
check is made at. for example, a web -site to determine 
whether the web site can Identify Visa and has access 
10 to Visa's publk; key. If the certificate issuer is known, 
then the digitalsignature of the certlicate issuer may be 
verified. 

Based upon the bkx:KaO analysis, a detemfiinatkxi 
is made as to whether the certificate issuer is known 

IS (82). If the certificate issuer is not known, then the di- 
rectory acts as a directory client to attempt to find a 
known certificate issuer. 

After the directory sewer acts as a directory client 
10 find a known certificate issuer, a check Is made at 

20 Figure6B. bkx:k84. todetermine whether a known cer- 
tificate issuer has been found. If so. the routine branches 
back to block 80. and the routmecontinues. If no known 
certlfk:ate issuer is found, then access is denied. 

An exemplary data structure or object utilized In 

2S conjunction with the bkxk 80 analysis is shown in Figure 
9 As shown in Figure 9. the certificate issuer's name is 
Identified by using the verification descriptor's client 
Identity and the issuer's Identity information. As shown 
in Figure 9. the verificatkin process utilizes the issuer's 

30 publk; key and verifkualion algorithm kientifier informa- 
tion. If the data structure shown in Figure 9 has a null or 
blank 'issuer public key" fieU. resolving the unknown 
certificate issuer may involve either storing informatkxi 
from another directory in a kxal cache, acting as a cfi- 

3S rectory sewk:e client toanotherdrectory sewice, or per- 
mitting an unknownsignatureby deferring resolutkxi un- 
til the access control rules are searched. By permitting 
an unknown signature to be utiized. theeyslem may ac- 
cept the unknown signature, while relying on the aooese 

40 control mles to detemiine whether this is appropriate. 
For example, certain web sites may not care who the 
certificate issuer is and. in fact, wish topromole the web 
site tobe accessed. Under thesedfcumetances. the ac- 
cessa>le control list mles may kidude epedfic restric- 
ts tions identifying the context where an unknotwn certifi- 
cate Issuer is involved. 

Turning back to Figure 6A. If the certificate issuer's 
public key is available, the directory sewces verifies at 
bkx:k 66 the digital signature, such that the digital slg- 
nature on the issuer's <:ertificate matches the internally 

Stored public key of the certificate iseuer 

figure 10 shows an exantple of an object cr data 
structure required to pertonn the veriication operations 
of FigureBA. bkxk 86. As shown in Figure 10. the client 
55 identity is used whch consists of the signed sequence 
embodied in a digital certifk:ate previously discussed in 
conjunction with Figure 4. The issuer's public key is also 
used which includes the information shown, including 
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an algorithm identtfier. Thus, the client identity, which is 
a signed sequence defined by a digital certificate, per- 
mits the signature to be verified with the issuer's public 
key. 

A checic is next nruide at Figure 6A. bloclces to de- 
termine whether the signature is good. If the signature 
Is bad, then as shown in Figure 6B. access is denied or» 
as previously described, a decision may be made to de- 
fer resolving this issue until the aocees control rules are 
checked. 

If the check in bksck 88 indk^tes that the signature 
is good. then, as indk:ated in bksck 90. the directory sen^- 
ice verifies that the certificate is stlH cun^ently vaBd by 
checking an internally stored certificate status or optkxi* 
alVt a check is made of an intemaOy stored certificate 
revocatk)n list. 

Figure 11 shows exemplary objects or data struc- 
tures whch may be used in performing the verifk»tion 
indicated at Figure 6A, block 90. As shown in Figure 11 , 
the client identity inlormation includes the digital certifi- 
cate prevKHisly discussed. The cert(lk:ate revocatkxi list 
is a list of certificates wheh have been previously re- 
voked and may be presented as attributes with an at- 
tribute-syntax certificate list. The list would be in the 
form of a signed sequence of cenificates as shown in 
Figure 1 1 The signed sequence includes the certificate 
serial numbers and the revocation oate The certificate 
revocation list wouki be prepared by the controlling di- 
rectory sen/ice entity. If the cenificate serial number 
ideniitying a client is stored in a certificate revocatk>n list 
kept at a directory service and the certificate is revoked, 
the certificate revocation list may only be modified by 
those who are property authorized. The revocatk>n list 
may be prepared and revised by an authority connecting 
to the directory service having more expansive rights 
than the typical client. Such authority woukj include the 
authority to write into such data structures as the certif- 
k^ate revocatkxi list. Such a connectk)n would typkatiy 
take place only with the directory service administrator's 
digital certificate. The directory service may not need to 
maintain a full certificate revocatkxi list since it may be 
oortstructed from the raw data stored in the directory 
senhce. Thus, information may be stored in the directory 
sen^k:e indk»ting that a particular certificate is not vaHd. 
Raw data stored in the directory service permits per cer- 
tificate k)okups for valk% purposes. The certificate rev- 
ocation list may be retrieved from a kx^al cache, from 
another directory servk:e or deferred until the ACL rule 
check. 

Turning back to Figure 6A. based on the processing 
in block 90, a check is made to determine if there is a 
valkl certifk»te (92). If there is not a vaiti certificate, as 
determined by the check in block 92. then connectkxi is 
denied or deferred as prevkxisly described. 

II there is a valM certificate, then, in accordance with 
block 94 processing, the directory cross-references the 
client certificate, the server cediticale and the commu- 
nications context to retrieve an inieinally stored access 



control rule to apply to the client oonnecton. 

Figure 12 diseases an exemptaiy object or data 
structure which may be used for the bkx:k d4, Figure 6 
processing, fbr retrieving an access control rule, an ex- 

s arrple of whKh is shown in Figure 13. The set of access 
control rules are defined in the directory senrice data- 
base. Various directory servers may be linked so that 
access control rulee stored in other directory senfers 
may be utilized and may be required in order to fuBy de- 

vo termine the access control niles that apply. The directo- 
ly senrers may be linked based upon prearranged con- 
tractual tnist relationships. For example, a trust relation- 
ship with a Visa card may require that Visa trust a given 
merchant and its cardhokfer. and that the merchant trust 

15 the Visa cardholder. The ACL njle is accessed by the 
server itself by use of the context and the client certifi- 
cate and the server^ certificate. An ACL rule is retrieved 
from the server's internal database, based on the client 
ktentity. the context descriptor (whfch may. for example. 

20 indicate whether E-mail or a web site related transactkxi 
is involved), and the server kjentity 

As shown in Figure 13. the ACL njle is a digital se- 
quence inchiding a to what* field. whk:h. for example, 
may indk»te that the rule applies to a web page. An ACL 

2S rule may also include parameters associated with the 
to what" fieW which may, for example, include a web 
page address or a credit card number, the nature of the 
card and/or the cardhokier's name. A *by what" 1 ieki may 
also be included, which typk:ally includes the clienrs 

30 certificate, which may be Mentified by a client ID. 'By 
what* parameters are iru:iuded whk:h may be, for exam- 
pie, a digital certificate. An 'access' fiek^ may also be 
included and is comprised of an integer defining the al- 
lowable directory access modes. By way of an example 

3S access integers 0-4 may reepectlvely indcate eeaich. 
compare, read, write or none. The access control nile 
may also inchide a version nunnber. 

if the certificate issuer's signature or the certificate 
revocatkm list checking operations were defended until 

40 Figure 6A,bkx:k 94 proceesing. then these events are 
passed on ae part of the context fieU ehown in Figure 
1 2. Addttionaly. thecertificata revocation list can be part 
of an access control rule list in the deferred case. Addi- 
tkxially. it is noted that trust levels can be defined In an 

4S access control ist rule. The access control nilee may be 
retrieved from a local cache memory, or from another 
directory servce. Umlts may be placed on any particular 
limitatkxi as to when access control rules must be kept 
local or when they may be retrieved from another direc- 

50 tory service. 

Turning back to Figure 6A. the access control mle 
is applied to the data connection eo that the client only 
receives the correct end intended data. The verification 
component thus returns an access rule to be applied for 

s$ the client to the server. 

While the inventton has been described in connec- 
tion with what is presently consktored to be the most 
practical and preferred embodiment, it is to be under- 
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stood that the Invention is not to be limited lo the difi- 
cloeed ennkxxiiment. but on the oontrafy, is intended to 
cover various modifications and equivatent arrange- 
ments included . within the spirit and scope of the ap- 
pended claims. 



Claims 

1 . A method lor providing secure communications be- 
tween a client at a first workstation and a computer 
comprifthg the steps of: 

receiving at said computer a request from said 
client for at least one of information and servic- 
es, said request including at least one digital 
certificate identifying said client; 
checking at said computer to determine if the 
issuer of said digital certificate is recognised; 
verifying that said digital certificate is valkJ; and 
retrieving, if the digital certificate is valid, an ac- 
cess control rule to apply lo the communication 
session with said client during which at least 
one of tntormation ar>d services is provided to 
said client 

2. A method for providing secure communicaiions be- 
tween a client at a lirst workstation and a computer 
comprising the steps of: 

receiving at said computer a request from said 
client for at least one of information and aenric- 
es. said request uruquely ktonlifying sakf client; 
checking at said computer to determine if the 
client is recognised by sakj computer; 
retrieving, if the client is recognised, an access 
control rule to apply to the communication ses- 
sion with saxj client during which at least one 
of infomtation and setvk^es is provktod to saki 
client; 

applying sakl access control rule to the oom- 
muncations sessk>n with said client. 

3. A method lor provkfing secure communicatkxis be- 
tween a client ata first workstatkNi and a computer 
comprising the steps of: 

receiving at said computer a request from said 
client ol at least one of information and servic- 
es, said request including at least one digital 
certificate kJerttifying aakl client; 
checkmg at said computer to determine if the 
digital signature in sakl digital certificate is val- 
kl;and 

retrieving an access control rule to apply to the 
communication session with said client during 
which at least one of information and sen^ices 
IS provided lo satd client 
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4. Amethodaocofdingtoanyoneof^claims 1 to3, 
wherekt eakJ computer includes an tntemal data 
base and wherein saM step of checking includes the 
step of checking to determine H the public key d an 
UentifiedcefUfled party is stored in sakJ internal da- 
ta base. 

6. A method for provUing secure oommunicattons be- 
tween a client at a rirel workstatksn couplsd to a net- 
woric including a plurality of computers comprising 
thestepsof; 

receiving at a first computera request from saM 
client for at least one of information and senric- 
es. saki request unquelyktsntifyingsakfclient; 
checking at eaki first computer to determine if 
the client is recognised; 
checking at a second computer coupled tosakJ 
network, to detemnine if the client is recognised; 
and 

retrieving from saU second computer, if thecU- 
ent is recognised, an access contiol nile to ap- 
ply to the conrvnunication sessksn with sakJ cli- 
ent during which at least one of informalkxi and 
services is provided to said client 

6. A method according to any one of claims 1 . 3. or 5, 
further including the step of applying sakJ access 
control rule to the communicatk>ns session with 

said client. 

7. A method according to claim 5. further including the 
step of kfontifying a second computer for operating 
as a server whk:h can verify the ktontily of saxi client 
and interconnecting sakl second computer with 
saU first computer via the Internet. 

a A method according to any one of claims 1 . 3, 4. or 
5. further including the step of accessing infbrma- 
t»n related to the degree of trust which nnayte as- 
sociated with sakl client 

9. A method according to daim 2 or daim 5» wherein 
sakl receiving step includes the step of unkfuely 
ktontiiying the client via adigital certak»te. 

10. A method according to daim 2 or claim 5. wherein 
sakJ receiving step includes the step of receiving 
data uniquely ktontifying the client induding the dl- 

ent's public key. 

11. A method according to daim 5. wherein sakJ first 
computer andeaM second computer indude an lr>- 
temal tlata base and whereineaki step of checking 

includes the step of checking to determine if the 
publk: key of an kJentif ied certifying part is stored in 
sakl internal xSaXa base. 
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12. A method according to any one of claims 1. 2. 3, or 
6, wherein eaid computer includes a directoiy and 
wherein said step of applying said access control 
rules includes the step of permitting the client to ac- 
cess said directory only in accordance wittt said ac- 
cess control rules. 

13. A method according to any one of claims 1 . 2. 3» or 
6. wherein said client requests access to a web site 
via said request and wherein said step of applying 
said access control rules includes the step of per- 
mittff>g the client to perform operations at said web 
site only In accordance with said access control 
rules. 

14. A method according to any one of claims 1.3. Of 9. 
further including the step of accessing information 
related to the degree of trust which may be associ- 
ated with said client. 

15. A method for prcvldir>g secure directory services 
communications between a client at a first worksta- 
tion and a computer comprising the steps of: 

transmitttng from a client's workstation a re- 
quest lor dtreclory services to said computer lor 
at least one ol inlormation and servtces said 
request including digital information for unique- 
ly establishing that said client has a known 
identity which can subsequently be unambigu- 
ously verified; 

checking to determine if the client is recognised 
by said computer. 

retrieving an access control mie to apply to the 
communk:ation session with said client during 
whk:h directory services is provided to said cli- 
ent; and 

applying said access control rule to the com- 
municatkxis session with said client. 

16. A method for providing secure communtcatior^ be- 
tween a client at a first workstation coupled to a net- 
work including a plurality ol computers, each of sakj 
plurality of computer including a directory sender 
and an associaled data base, comprising the steps 
of: 

transmillmg Irom said first workstation lo a first 
computer of said plurality of computers a re- 
quest from said user lor at least one of inf orma- 
tk3n and services, said request unk^uely identi- 
fying sakJ client; 

checking by the first computer's directory send- 
er, the associated data base at said first com- 
puter to determine if the client is recognised by 
said first computer; 

checking by the second computer's directory 
server the associated data base ai said second 



oorrvHiter coupledtoeaU network. todetemUne 
I the client is recognised; and 
retrieving from sab second computer, if the clj- 
ent is recognised, an access control niletoap- 
s ply to the oommunicatkx)sess»n with sab cli- 

ent durktg which at least one of information and 
aenrices is provided to sab client. 

17. A method according to claim 16, further including 
10 the step of accessing trust related information from 
the internal data tiase of eab second computer. 

ia A method according to claim 17. further Muding 
the ^ep of applying the tnist related inf ormatton and 
IS the access control nile to the dienTs request to en- 
sure that authorisation levelB are not exceeded. 

19. A method according to claim 17, wherein sab re- 
quest is a request for an electronic business trans- 

20 action transmitted to a web site. 

20. A method according to claim 17, wherein the re- 
quest is a request for a business transactk)n and 
wherein the sewer which recognises the client de- 

2S velops transaction parameters in the context of the 
parties involved. 

21 . A method according to claim 17, wherein said trans- 
mitting step includes the step of uniquely identifying 

30 the client via a digital certificate. 

22. Amelhodaocordingtoclaim17.whereinsabtrans- 
mitting includes the step of transmitting data 
unk)uely identifying the client including the ctienfs 

3S public key. 

23. A method according to daim 17, wherein sab step 
of checking by 6»d first computer's directoiy eenrer 
includes the step of checking to determine if the 

40 pubUc key Of an bentified certifying part is Stored irt 
sab associated internal data base. 



24. A method according to claim 17. further InchJding 
the step of applying sab access control rules to per- 
mit the client to access sabdirectory only in accord- 
ance with sab access control rules. 



45 



2S. A method according to claim 17. wherein sab client 
requests access to a web site via sab request and 
so further including the step of applying sab access 
control rules to permit the cUent to perform opera- 
tions at sab web site only in accoredance with aab 
access control rules. 

^ 26. A method for provbing secure directory sendees 
communicatkxis between a client at a first worksta- 
tion and a computer having a directory server com- 
prising the steps of: 
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transmitting from a clienfe workstation a re- 
quest for directory services to said computer 
said request from said client tnctuding at least 
one of information and services, said request 
Including a digital certificate for uniquely estab- 
lishing that said client has a known ktontity 
which can subsequently be unambiguously 
verified; 

verifying by saki directory sender the authorisa- 
tkin for the server to comply with the request 
based upon at least one di^ certificate and 
informatkxi related to the request context; and 
retrieving an access control rule to apply to the 
communicatkxi sesskxi wrth saU client during 
which directly sen^ices is provkted to saki cli- 
ent. 

27. A method according lo claim 26 further including 
the step ol applying said access control rule to the 
communications sesskxi with said client. 
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subsequently be unambiguously verified; 
a directory eerver module for responcSng to md 
request; and 

a datM»se for storing inlomnatnn indk»tive of 
the public key of the issuer of the clienfs digital 
cert9k»te and for storing access ^control rules 
to apply to requests; 

saM directory sen/er module being operable to 
verify the authorisation for the server tocomply 
with the request based upon at least oneifigital 
certricate and information related to the re- 
quest context and for retrieving an access con- 
trol rule to apply to thetxsmmunicatnn sessxm 
with sakI client during which cfireclory services 
are provkted to sakI client. 

Apparatus according to claim 33. herein sakl <fi- 
rectory server module to operable to apply saki ac- 
cess control rule is applied to the communk:ations 
sesskx) with saki client. 



28. A method according to claim 26. wherein saki re- 
quest includes the client's public key 

29. A melhod according to claim 26. where«n said com- 2B 
yAi\et includes an internal data base and wherein 
said step ot verilying includes the step ol checking 

to determine if the public key ol an identified certi- 
fying parly is stored in said internal data base. 

30 

30. A method according to claim 27. wherein said com- 
puter includes a directory and wherein saki step of 
applyir^ saki access control rules vKludes the step 
of permitting the client to access saki directory only 

In accordance with saki access control niles. ^ 



31 . A method according to daim 27. wherein said cbent 
requests access to a web sKe via saki request and 
wherein saki step of applyrg saki access control 
rules inckides the step of permitting the client to per- 40 
f omi operatkm at saki web site only in accordance 
with saki access control rules. 



32. A method according to daim 15 or claim 26. further 
Including the step of accessing informaton related 4B 
to the degree of tmst which may be associated with 
said client 



33. Apparatus for providing secure directory services 
while responding to a request for information or so 
sen^ices by a client at a first wortcstation comprising: 



a secure communications input module for re- 
ceding from saki clienfs workstatksn a request 
tor directory services including al least one of ss 
intormation and sen/ices, said request includ- 
ing a digital certiticate for uniquely establishing 
thai said client has a known identity which can 
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Fig. 3 














^3a Cliei4 inmates communicaBons 

ai QDBiWnO ID 3 HmMKMIC GOUnfiChOft 
to 1h6S6fV6f 




Server 




Cilent 


^ Sefver responds to connecfon, 
and demands idenfificatjon 






^3c Ctentsends identity iorltiis session, 
Bi the form of a digital certificate. 





^62 ^60 



Fig. 4 



Certificate ::= SIGNED SEQUENCE{ 

version lOJVersion DEFAULT 1988. 



seri^Number 
signature 
issuer 
vaicft/ 
sutiect 

sutJjectPuticKeylnfo 

Version 
SeriaMumber 
Validity 

notSelbre 
notAfter 

SubjectPulJlicKeytnfo 

algorithm 
sut^ectKey 



serlalNunfter. 
AigoriMdentifier 
Name 
yarufity. 
Name, 

SubjectPuUicKeylnfo} 



64 

u 



= INTEGER {1988(0)1 
= INTEGER 
:= SEQUENCE { 

UTCTme. 
UTCTime) 
: SEQUENCE{ 
Algorilhmldenlllier 
BIT STRING] 
Aigorithmidentirter ::= SEQUENCE! 

algorithm OBJECT IDENTIFIER 
parameters ANY DEFINED BY atoorithm 
OPnONAL) 
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ROMI 
FIG.S 



Client identity (dgitalcertiiicate), 
Coflununications Context (context 
descriptor), and Sender Identdy 
(digltaiceffflcate) 



Fig.6A 



HTO 
ifl&6B 



The directory servicechecks that the (figital cerfficate 
issuer's pid)6c key is available to ttie cfirectory service 



X 



ao 



86 




No 



The directory service verifies that the digital signature 
on the certifcate matches the internally stored public key 
of the certificdte issuer 



FROM 
FIG. 5 



90 




No 



The (firectory service verifies tat Ihe certificate is stiS currently 
valid by checidng the intemaly stored certificiate status, or optionaly 
against an internally stored CeriiV Revocation List 




No 



The directory aoss references the cBent certificate, the sen^r 
certificate^ and ihe communications context in order to retrieve an 
internally stored Access Control Rule to apply to the client connection 



Verificatimconnponent returns 
an Access Rule for the Client 
to Server Session to block 76 



jflG.1 
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R&6A 



No 



No 





Act as a directory 
service cient to 
find a known 
Certificate Issuer 

Return: 

Connection Denied 
or Defended 



No Access 



No 




Return: 

Connection Denied 
or Deferred 



Fig.6B 



FROM 
FIG.6A 
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Veriiication.Oescnptor 


•j= SEQUENCE! 


CHentidentity 


Certificate, 


ContextDescr^tor 


^ - _ * m. 

Context, 


Server iderdit/ 


Cerliicale} 



Fig. 8 



Context 



\fersion 



SEQUENCE! 
version 
time 
protocol 
parameters 



(OlVersion DEFAULT 1996. 
UTCTime, 

OBJECT IDENTIFIER 
ANY DEFINED BY protocol 
OPTIONAL} 
r INTEGER {1S96(0) } 



Fig. 9 



IssuerName = Verilicalion Oescfiptor->Clienti(J6nlity->lssuer 
IssuerPublicKey = ::= SEQUENCE { 

algorilhrn Aigorithmidentirier 
Key BfT STRING) 

::= SEQUENCE! 

OBJECT IDENTIFIER 
parameters ANY D^INED BY algorithm 
OPTIONAL) 



Fig. 10 



CSentidentity SIGNED SEQU8«1CE! 

IssuerPublicKey = ::= SEQUENCE! 

algorithm Algorithmidentifier 

Key BIT STRING) 

Algorittimidenlifler ::= SEQUENCE! 

algorithm OBJECT IDENTIFIER 

parameters ANY DEFINED BY algorithm 
OPTIONAL) 
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aientidentity Certificate 
CertiiicateRevocationList ATTRIBUTE 

WITH ATTRIBUTeSYNTAX-CertilicateUsl 
AuthorilyRevocationList ArrRiaTTE 

WITH ATTRlBUTE-SYI^AXCertlicateList 
CertiiicateList SIGNEDSEQUENCE{ 



issuer h^e. 
lastUpdate UTCTme, 
revokedCertificates 



SIGNED SEQUENCE OF SEQUENCE{ 
signature Algorlthmidentifier, 
issuer Name.CertificateSerialNumber^ecl, 
revocalior^ate UTCTime) 
OPTIONAL) 



Fig. 12 



ACL = Relrieve.ACL from Internal 
ContextDescriptor, Sen«ridentity) 



Fig. 13 



Aa.Rule ::= SEGUENCEI 

towhat OBJECT lOENTIFien. 

lowhatjjarafneters ANY DEFINED BYiowhat 

OPTIONAL 
tjywhat OBJECT lOENTIFIEfl, 

bifwhatj)arameters ANY0EFINE06Yt)ywtuit 

OPTIONAL 
access IhfTEGER} 

Version ::r INTEGER { 1998(0) } 
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